Running a source code (e.g. a script or a computer program in high level computer languages) during run time usually consumes too many processing cycles to be practically desirable. For example, graphics processing tasks often require making a large number of decisions in a state machine to process a single pixel. Even though multiple graphics libraries can be assembled together in the state machine, overall performance of graphics processing tasks can be severely degraded by the sheer number of possible branch possibilities involved. Typical attempt to reduce the number of branches to consider for performing graphics processing may include code optimization by compiling source codes, for example, using a JIT (just in time) compiler.
However, traditional graphics compilers can be resource intensive, taking up a large amount of memory space and/or processor time. For example, typical code size for a compiler can be large. If an application links a library that uses a compiler, a virtual memory cost of a massive amount of compiler code may be imposed on the application, even if the compiler is never executed by the application. In addition, compilers tend to require large amount of private memory during run time (e.g. private memory hogs) because intermediate results may be cached for compilation performance. Thus, an application using a run time compiler, such as a JIT compiler, to generate compile codes may tax a significant part of the limited system resource.
Furthermore, compiled codes may not be shared for compilers implemented in shared libraries. For example, many applications requesting the same task may compile the same code in several process spaces, each for a separate application, without sharing. Additionally, applications may have to repeatedly compile the same source code for specific tasks during start up. Thus, application start up times can suffer.
Furthermore, many compilers are not designed with high robustness and tight security right from the start. Because running typical compilers allows an application to generate codes for execution, security holes may exist for malicious application codes to take advantage of. Usually, a shared security environment for running a compiler and a calling application tends to introduce security risks to each other. In addition, a compiler can be unstable (e.g. can crash unexpectedly). When calling a run time compiler, a calling application often crashes if the run time compiler crashes. As a result, a calling application may not have an opportunity to recover from a compiler failure.
Therefore, computing systems with applications running traditional run time compilers tend to be slow, unstable and insecure.